I just got this too. I’ve never seen this before. Any updates?

Don’t set horizontalSizeClass, that fixed it for me. Why are you setting it anyway? This is a value that is set by the system and probably should not be overridden.

It sounds like you’re holding on to a reference you shouldn’t be. window will be nil if the view of the view controller is not in the view hierarchy. So that can mean you’re making the tableview try to layout either before it’s actually been pushed, or after it’s been popped. ViewControllerB is likely getting deallocated when it moves off screen. Then when you push ViewControllerB it is a new instance, and your service that updates the table view is likely trying to reference the old View Controller. Your data source probably shouldn’t know anything about the view controllers. If your service doesn’t reference the view controller directly then you may have a retain cycle in the methods that you’re observing the updates.

You can import Sketch files into Figma

Not sure what the purpose of passing in all the items into each sub view. I’m not able to reproduce your crash in a playground, but i was getting a lot of calls to sub views when adding an item because you’re passing in the items as a binding. I removed the binding from the SubView and only passed in the number for each SubView. That stopped the Subviews from updating when adding items: import SwiftUI import PlaygroundSupport import SwiftUI struct ContentView: View {     var body: some View {         TestView(items: [1, 2, 3, 4, 5])     } } struct TestView: View {     @State var items: [Int]     var body: some View {         NavigationView {             VStack {                 Text("Hello")                 List {                     ForEach(items, id: \.self) { item in                         NavigationLink(destination: SubView(number: item)) {                             Text("\(item)")                         }                     }                 }                 Button(action: {                     self.items.append(self.items.count + 1)                 }) {                     Text("Add")                 }             }         }     } } struct SubView: View {     var number: Int     var body: some View {         Group {             Print("\(number)")             Text("\(number)")         }     } } extension View {     func Print(_ items: Any..., separator: String = " ", terminator: String = "\n") -> some View {         let output = items.map { "\($0)" }.joined(separator: separator)         Swift.print("→ " + output, terminator: terminator)         return EmptyView()     } } PlaygroundPage.current.setLiveView(ContentView()) I think it might be that you’re doing something that holds on to the reference of the items longer than you should or. You might try two things. If possible, don’t pass in those items and remove the binding in the Subview If that is needed for some reason further down look at any blocks you have where you might be creating a retain cycle that would keep those subviews alive longer than they should. Look up retain cycles in blocks for help, also look in to weak vs strong references. You might have some objects that point to each and never get released. good luck

Update 2: Deleting cache only worked temporarily after removing adding devices. I'm giving up, I think we'll need to wait for Apple to solve. Update 1: I attempted to delete any Xcode (e.g. com.apple.dt.Xcode) folders/files in the caches folder ~/Library/Caches. I can build again to my watch, for now Same here. It briefly worked shutting down both phone and watch, removing the phone from the list of paired devices, removing my ADC account and then re-adding, booting everything up. I was able to debug on the watch, then something happened and it went back to being broken. I haven't bothered again since then.

I'm having the same issue, I've tried both on Monterey and Big Sur. I think we'll need to wait for an update of Xcode.

This is happening to me too, I was hoping this post would help me out. I've been suffering from this for several days, so not resolving for me. One thing I'm curious about, are you using a Watch App + Extension (old style) or just a Watch App? Apple's example code is still using the old style and works perfectly. For me, the watch can send messages to the phone, but the reply never comes back to the watch.

Still seeing in Xcode 14.0.1

Experiencing the same on Xcode 14.2

Just so this gets bubbled up more this answer colink (Apple wouldn't let me post a direct link ) about mid-way through the comments solved it for me. The tldr; is double check that the groups in your Xcode project have the same capitalization as the folders on disk. Mine had a discrepancy between the root folder name capitalization. Now my errors reliably show. Thank you colink

Fixed! Double check the capitalization of your project path vs your folder capitalization. When mine were mismatched (e.g. /Users/username/Git/Path/To/Project/Project.xcodeproj with a folder path of /Users/username/git/path/to/project/project.xcodeproj) I had this problem. Once I updated them to match the capitalization It worked. In Xcode select the project (first item in navigation list), show the file inspector and look at where it says Full Path, then compare to your folder structure in Finder

I ran into this too. I tried a few different ways that didn't work. Using combine to observe the values didn't work, but I did some digging and found something that might be viable, although it's a little convoluted. So @Observable is not just making something conform to ObservableObject, it's its own thing, it's writing some of your code for you. So if you expand the macro (right click on @Observable) it will expand the code it's augmenting your code with. You'll see a bunch of @ObservationTracked macros revealed for your properties. There's some other stuff too, but not specific to your property. @ObservationTracked var test: String = "" ... @ObservationIgnored private var _test: String If you expand that macro you now see the getter and setter for your property: @ObservationTracked var test: String = "" { get { access(keyPath: \.test) return _test } set { withMutation(keyPath: \.test) { _test = newValue } } } ... @ObservationIgnored private var _test: String Now you have hooks into setting the new value. So you can do something like this: @ObservationIgnored #Flip this to ignored because you're doing your own manual getter/setter# var test: String { get { access(keyPath: \.test) return _test } set { withMutation(keyPath: \.test) { _test = newValue #do your cool thing here# } } } ... @ObservationIgnored private var _test: String = "" #don't forget to move your initial value here# So with very light testing this seemed to work as expected. YMMV. I think we'll just have to see if this is a pattern, or if Apple can provide us a way to annotate properties we want a didSet hook for. Either way this might be the exact kind of use case we could write our own macro for. But I'd prefer if Apple solves this. I'm going to file a bug with Apple immediately to request they give us a built in solution. If we want to get it fixed, I think Apple needs to hear about and very soon so it still has a chance in getting in this year.

Do the query and data case match? It doesn’t currently support case insensitive queries. A major oversight on their part. I filed a bug and you should too if this is your issue. If the issue is the relationship, you should file that too.

I think you want to change @Binding to @Bindable from: struct ListView: View { @Binding var listDataArray: [DataType] } to: struct ListView: View { @Bindable var listDataArray: [DataType] } I worry that you might have unexpected consequences to add the @Bindable in the body